Once you can identify the code module,
what can you do with it?

Naming Conventions:

The code module is generated with the assumption that the Urthman's MDB Code Generator has been (or will be) used to generate the main code module(s) for the database itself. All references to data variables revolve around this assumption, using the naming convention standardized by that code generator.

Urthman's MDB Code Generator naming convention: The main database code module name would be derived from the actual file name, where a database file named MyData.mdb would result in a code module named mdbMyData.bas. The table name(s) subsequently drive the subroutine name variations, and combined with the field names, create the data variable names around which both programs revolve.

For example, a variable named mdbMyData.MyTable_FirstName would refer to a field named FirstName in a table called MyTable in a data file named MyData.mdb. This is both simple and logical and should therefore be easy to follow and track.

The Urthman's MDB Construction Kit, as an extension of the MDB Code Generator, generates import and export code in a module of its own. Taking the database file name in the above example, the MDB Construction Kitwould create a code module file named mioMyData.bas, where the 'io' stands for input and output.

Exporting headers using comma delimited file formats is a relatively transparent process. If the designated output file does not exist, then the first record written when the file is opened for export is the header record. If the file does already exist, then no header record is generated. This header record contains the column headings for the data records that follow that header. This allows for quick referencing and import into a standard spread sheet for sorting, editting and reporting data.

Fixed length records use headers and trailers for supplemental data and control. For this purpose, a set of data variables for each header and trailer record is made available in the code module, accompanied by a matching Export subroutine. Populate the data variables and export the header or trailer record.

Importing headers in comma delimited formats is used to "realign" column data with the table fields. Generally, the first record in a comma delimited file is the header record, and if present, these heading fields correspond to table field names. Refer to the code module comments for more detailed information since some criteria depend entirely on the structure of the data file.

Importing headers and trailers with fixed record length files is a slightly more complex exercise. The header records generally open with data related to the detail records that follow and the common element terminates with a trailer record that contains summary information (i.e., record count or revenue total) to serve as a data integrity check. A subsequent header resets the common information for another batch of detail records.

The MDB Contruction Kit permits the definition and application of header and trailer record layouts, including up to three fields whose content can identify which header or trailer is being encountered. These recognition codes are used in the generated code for (1) recognizing and reporting the encounter of any header and trailr record and (2) to pass default values into the header and trailer records during export.

A public variable called RecType will contain a code identifying the type of record encountered during an import pass. The following code sample demonstrates all of the import data functions and options.

The import routines are heavily commented, including indicating where certain operations can take place to prevent unwanted data overwrites. This is primarily a function of comma delimited file exchanges. The strategy involves exporting data to a comma delimited file and importing this data into a spread sheet for review, analysis and edits. After making these adjustments, some columns may have been moved around for the convenience of the user, and some insignificant columns may have been deleted.

During the standard import sweep, the column headings allow for proper realignment with the original corresponding table fields, however, the deleted columns would result in null data being written into that field. In order to preserve the previously populated data of those deleted columns, a record-find operation can be called. This serves two purposes: (1) to populate the deleted column fields with "Default" data and (2) to clear or neutralize ALL data fields prior to generating a new data record.

The optimal location and method for this function are fully commented in the specific import routine. This code makes the assumption that the Urthman's MDB Code Generator has been or will be used for creating the general code module for all other database functions.